cache source and --force for type checkers#23109
cache source and --force for type checkers#23109cburroughs wants to merge 2 commits intopantsbuild:mainfrom
Conversation
This started as adding --force because I had confused myself several times benchmarking and forgetting to dirty the right cache at the right time. I think that like `--test-force`, `--check-force` "shouldn't" be needed, but sometimes it is. (Since the case is more marginal for checking we could make it `advanced`, but leaned towards the consistency with the test goal.) I couldn't mirror the `--test-force` test without widening the scope to pass along `RunId`. That was added for pantsbuild#13889 which would also be valuable for all the same reasons exposing that information for tests was. (To be clear, I was not aware that `pants check ::` could be "cached locally"!) The Golang/JVM subsystems approach type checking is different (aka the compiler does it) and are thus unchanged. Typescript is another different challenge because it partitions by directory. Added a flag so that typescript can retain the old 'single line' `✓ typescript succeeded.` behavior since getting a line for each directory seemed like far too much. (I fiddled a bit with trying to get repositories with only a single (resolve,IC) to omit the partition name but I didn't like what the coupling looked like.)
1e584d6 to
5c04793
Compare
|
(Re test failure --> #23108) |
|
I didn't realise the --test-force option existed for tests. Should it be added here? docs/using-pants/troubleshooting-common-issues How would users expect this to work with named_caches - e.g. the mypy cache? As proposed, mypy cache would still be used. Thanks for the report re. node lockfiles. |
I'd at least expect all the named caches to still be used (just like |
docs/notes/2.32.x.md
Outdated
|
|
||
| #### Check | ||
|
|
||
| For those language ecosystems that use separate type checkers from compilers (So Python, but not JVM languages or Golang for example), the `check` goal now includes a `--force` flag that works like the `test` goals's `--force`. Use it for benchmarking or debugging rare problems. Supported languages now also include a cache status hint similar to the `test` output. So using the Pants repository it self as an example, output might like like: |
There was a problem hiding this comment.
last sentence - "it self" -> "itself", and "output might look like"
src/python/pants/core/goals/check.py
Outdated
| only = OnlyOption("checker", "mypy", "javac") | ||
| force = BoolOption( | ||
| default=False, | ||
| help="Force checking to run, even if they could be satisfied from cache.", |
There was a problem hiding this comment.
Grammar - "force checks to run"... (if they) ?
Got it, thanks. |
This started as adding --force because I had confused myself several times benchmarking and forgetting to dirty the right cache at the right time. I think that like
--test-force,--check-force"shouldn't" be needed, but sometimes it is. (Since the case is more marginal for checking we could make itadvanced, but leaned towards the consistency with the test goal.)I couldn't mirror the
--test-forcetest without widening the scope to pass alongRunId. That was added for #13889 which would also be valuable for all the same reasons exposing that information for tests was. (To be clear, I was not aware thatpants check ::could be "cached locally"!)The Golang/JVM subsystems approach type checking is different (aka the compiler does it) and are thus unchanged.
Typescript is another different challenge because it partitions by directory. Added a flag so that typescript can retain the old 'single line'
✓ typescript succeeded.behavior since getting a line for each directory seemed like far too much.(I fiddled a bit with trying to get repositories with only a single (resolve,IC) to omit the partition name but I didn't like what the coupling looked like.)